Method and apparatus for automatic frame type detection in a network

ABSTRACT

A method and apparatus for automatic frame type detection in a network automatically identifies at least one frame type in use on a network. The method then selects one of the at least one frame types for a device coupled to the network to use.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention pertains to networks and network protocols.More particularly, this invention relates to automatic frame typedetection in a network.

[0003] 2. Background

[0004] Computer systems are becoming more and more commonplace ineducational, business, and personal fields. As more and more individualsare using computers, it is becoming increasingly commonplace to couplemultiple computers together in a network. A wide variety of networks andnetworking protocols exist and, in order for a computer system on anetwork to access another computer system on the network, the twocomputer systems must typically be following the same protocol.

[0005] One difference between protocols is the way in which informationis “packaged” together for transfer over the network. Protocolstypically define a format for a “frame”, which is a series of contiguousbits transferred over the network. The format of the frame is referredto as the “frame type” and a single network can typically supportmultiple different frame types. The meaning of the bits in a frame isdefined by the protocol and varies between protocols. Thus, in order fora device that is newly added to a network to accurately interpret datafrom another computer system received via the network and communicatewith other devices on that network, the new device must know what frametype to use.

[0006] A new device to be added to a network is configured to use aframe type which is compatible with other devices on the network. Adevice can typically be configured by having a user input the frame typeto the device. This input can be carried out by, for example, a userinput to the device during installation, such as through theinstallation software, or by the setting of physical switches or jumperson the device. Such solutions, however, can pose problems duringinstallation, particularly when the user adding the device to thenetwork has little or no knowledge of the frame types supported on thenetwork, or even of what a frame type is.

[0007] Additionally, the modern trend is towards more user-friendlydevices. However, requiring a user to be knowledgeable about the frametype on a network is more user-unfriendly. Thus, it would be beneficialto provide a way to automatically identify a frame type for a device ona network.

[0008] Furthermore, some devices have no consoles or displays whichallow a user to input a frame type through the installation software.One such device is the Instant Internet¹⁰⁰™ device available from BayNetworks, Inc. of Santa Clara, Calif. Such devices are typically set upremotely by another computer system over the network. These devicespresent a particular problem because they communicate over the networkwith a remote system to be set up, yet they are unable to communicateover the network until they are set up.

[0009] Thus, a need exists for a method and apparatus for automaticframe type detection in a network.

SUMMARY OF THE INVENTION

[0010] A method and apparatus for automatic frame type detection in anetwork is described herein. The computer-implemented method of thepresent invention automatically identifies at least one frame type inuse on a network. The method then selects one of the at least one frametypes for a device coupled to the network to use.

[0011] According to one embodiment of the present invention, at leastone frame type is automatically identified by issuing a plurality ofdifferent requests on the network each using a plurality of differentframe types, and then checking which requests and which frame typeselicit responses from other devices on the network.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings, in which likereferences indicate similar elements and in which:

[0013]FIG. 1 is a block diagram illustrating a network architecture suchas may be used with one embodiment of the present invention;

[0014]FIG. 2 illustrates a frame such as may be used with one embodimentof the present invention;

[0015]FIG. 3 is a flow chart illustrating the steps followed inautomatically detecting the frame type of a network according to oneembodiment of the present invention;

[0016]FIG. 4 is a block diagram illustrating a network system in whichone embodiment of the present invention is practiced;

[0017]FIG. 5 illustrates a hardware system or machine on which oneembodiment of the present invention can be practiced; and

[0018]FIG. 6 is a block diagram illustrating a device on which oneembodiment of the present invention is implemented.

DETAILED DESCRIPTION

[0019] In the following detailed description numerous specific detailsare set forth in order to provide a thorough understanding of thepresent invention. However, it will be understood by those skilled inthe art that the present invention may be practiced without thesespecific details. In other instances well known methods, procedures,components, and circuits have not been described in detail so as not toobscure the present invention.

[0020] In alternative embodiments, the present invention may beapplicable to implementations of the invention in integrated circuits orchip sets, wireless implementations, switching systems products andtransmission systems products. For purposes of this application, theterms switching systems products shall be taken to mean private branchexchanges (PBXs), central office switching systems that interconnectsubscribers, toll/tandem switching systems for interconnecting trunksbetween switching centers, and broadband core switches found at thecenter of a service provider's network that may be fed by broadband edgeswitches or access multiplexors, and associated signaling, and supportsystems and services. The term transmission systems products shall betaken to mean products used by service providers to provideinterconnection between their subscribers and their networks such asloop systems, and which provide multiplexing, aggregation and transportbetween a service provider's switching systems across the wide area, andassociated signaling and support systems and services.

[0021] Some portions of the detailed descriptions which follow arepresented in terms of algorithms and symbolic representations ofoperations on data bits within a computer memory. These algorithmicdescriptions and representations are the means used by those skilled inthe data processing arts to most effectively convey the substance oftheir work to others skilled in the art. An algorithm is here, andgenerally, conceived to be a self-consistent sequence of steps leadingto a desired result. The steps are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like. It should be borne inmind, however, that all of these and similar terms are to be associatedwith the appropriate physical quantities and are merely convenientlabels applied to these quantities. Unless specifically stated otherwiseas apparent from the following discussions, it is appreciated thatthroughout the present invention, discussions utilizing terms such as“processing” or “computing” or “calculating” or “determining” or“displaying” or the like, refer to the action and processes of acomputer system, or similar electronic computing device, thatmanipulates and transforms data represented as physical (electronic)quantities within the computer system's registers and memories intoother data similarly represented as physical quantities within thecomputer system memories or registers or other such information storage,transmission or display devices.

[0022]FIG. 1 is a block diagram illustrating a network architecture suchas may be used with one embodiment of the present invention. A networkarchitecture 100 is illustrated including network communication control“layers” 103 and 104 on two hardware systems 101 and 102, respectively.Examples of such hardware systems include computer systems, gateways,routers, etc. Hardware system 101 includes a data link layer 110, anetwork layer 115, and a transport layer 120. Different applications andnetworking protocols can communicate over the network using networkarchitecture 100. Data to be transferred from hardware system 101 tohardware system 102 over the network is received by transport layer 120from higher level applications (not shown). Transport layer 120 isresponsible for ensuring that all of such data is correctly transferredto/from the target/source via the network.

[0023] The transport layer 120 communicates with the network layer 115.Network layer 115 separates the data from transport layer 120 into oneor more packets and is responsible for determining how these packets areto be transferred to/from other devices on the network. According to oneembodiment of the present invention, the network layer 115 supports theInternetwork Packet Exchange (IPX) protocol. The network and data linklayers which support the IPX protocol are also referred to as the IPX“stack”.

[0024] The network layer 115 communicates with the data link layer 110,which in turn communicates with the physical layer 105. Data link layer110 encapsulates IPX packets received from network layer 115 into aframe for transfer over the physical layer 105. Thus, network layer 115and higher layers can operate without concern for the frame type(s)being used on the network. The frame type into which the IPX packet isencapsulated is dependent on how the particular device is configured.

[0025] Hardware systems 101 and 102 are coupled to one another via thephysical layer 105. According to one embodiment of the presentinvention, the physical layer 105 is an Ethernet network. An Ethernetnetwork is typically capable of supporting at least four different frametypes. Four common frame types are: Ethernet_II, IEEE 802.2, IEEE 802.3,and Ethernet_SNAP. Each of these four frame types are well-known tothose skilled in the art and thus will not be discussed further exceptas they pertain to the present invention. However, in alternateembodiments, different frame types and/or different networks aresupported. For example, in one such alternate embodiment a token ringnetwork is supported.

[0026] As illustrated, hardware system 102 includes a data link layer130, network layer 135, and transport layer 140. These layers ofhardware system 102 operate analogously to those of hardware system 101.Data received by hardware system 102 from hardware system 101 viaphysical layer 105 is transferred to the data link layer 130. Data linklayer 135 extracts the IPX packet(s) from the frame. It is to beappreciated that such extraction is dependent on the frame type.

[0027] The IPX packet is then transferred to network layer 135, whichensures the transfer of data to transport layer 140 in the proper orderin accordance with the IPX protocol. By way of example, packets may bereceived by hardware system 102 in a different order than they were sentby hardware system 101—network layer 135 ensures that the properordering of packets is obtained before passing the data to transportlayer 140. Transport layer 140 then provides the received data to thehigher-level applications (not shown) of hardware system 102.

[0028] The multiple layers of network architecture 100 are well-known tothose skilled in the art, and thus will not be discussed further exceptas they pertain to the present invention.

[0029] Hardware system 101 also includes frame type detection control180. Frame type detection control 180 interacts with data link layer 110during initialization of system 101 in order to automatically detectpossible frame types which system 101 may be configured with. Frame typedetection control 180 directs data link layer 110 to issue multiplerequests using multiple frame types as discussed in more detail below.

[0030]FIG. 2 illustrates a frame such as may be used with one embodimentof the present invention. A frame 200 is illustrated including a headerportion 205, a data portion 210, and a tail portion 215. Data portion210 includes the data being transferred in the frame, illustrated as IPXpacket 220. Tail portion 215 includes different control information,such as a checksum, dependent on the frame type. Header portion 205includes a destination identifier 206, a source identifier 207, andadditional information 208.

[0031] As discussed in more detail below, a network can be made up ofmultiple network segments coupled together by one or more servers,routers, gateways, bridges, etc. Destination identifier 206 identifiesthe destination for the frame within a network segment while sourceidentifier 207 identifies the source of the frame within the networksegment. The destination identifier 206 and the source identifier 207are both six bytes on an Ethernet network. The additional information208, however, includes different information, and can be differentsizes, for different frame types. For example, if frame 200 is anEthernet_II frame, then the additional information 208 is “type”information regarding the remainder of the frame. However, if frame 200is an IEEE 802.3 frame, then the additional information 208 is lengthinformation which identifies the length of the frame 200. Thus, giventhe different information that can be stored in the header portion 205as additional information 208, it is important that the device know theparticular frame type in order to communicate with other devices overthe network. Otherwise, a receiving device may incorrectly interpret thedata of a frame.

[0032] The IPX packet 220 includes a packet header 222 and packet data224. The packet data 224 is the information that is being transferred bythe transport layers of the communicating devices. A packet header 222includes various control information regarding the packet data 224 aswell as the source and destination networks and nodes.

[0033] The destination network identifier 242 allows the data 224 to betransferred between network segments. For example, for a packet which isto be transferred from a first device on a first network segment to asecond device on a second network segment, and with the first and secondnetwork segments being coupled together via a router, then thedestination network identifier 242 identifies the second network segmentwhile the destination node identifier 244 identifies the second device.When the frame is transferred from the first device to the router theframe has, as destination identifier 206, the router. Upon receipt ofthe frame 200, the router identifies the ultimate destination of theframe 200 (based on identifiers 242 and 244) and issues the frame on thesecond network segment with a destination identifier 206 of the seconddevice.

[0034] Additional control information is also included in packed header222. A destination socket identifier 246 is included which identifies aparticular socket of the destination device to receive the frame.Network identifier 248, node identifier 250, and socket identifier 252for the source of the frame are also included. A checksum 254 isincluded for error checking/correcting purposes, and the length of IPXpacket 220 is included as packet length 256. Transport controlidentifier 258 identifies the number of routers through which packet 220passes between the source and destination nodes, while packet typeidentifier 260 identifies the type of packet. The contents and use ofpacket header 222 are well-known to those skilled in the art and thuswill not be discussed further except as they pertain to the presentinvention.

[0035]FIG. 3 is a flow chart illustrating the steps followed inautomatically detecting the frame type of a network according to oneembodiment of the present invention. The steps of FIG. 3 are carried outby a particular device on the network to identify one or more frametypes which may be selected from for use by that device. In oneimplementation, the steps of FIG. 3 are carried out by frame typedetection control 180 in conjunction with data link layer 110 of FIG. 1.

[0036] The device first embeds a service advertising protocol (SAP)request in each of multiple different frame types and issues the frameson the network, step 305. According to one implementation, therequesting device is pre-programmed with each of the possible frametypes for the network, as well as the protocols for those frame types,thereby allowing the requesting device to send a frame using each ofthese different frame types. In the illustrated embodiment, a request isissued in step 305 for each of these possible frame types.

[0037] The SAP request is made by setting the destination socket of theIPX packet (identifier 246 of FIG. 2) to be that for service advertisingpackets (e.g., 0×0452) and inserting a SAP request into the packet data(identifier 244 of FIG. 2). In one implementation, the SAP requestissued by the device requests the address of the nearest file server.All IPX file servers that are using the selected frame type and that areon the same network segment as the device will understand the SAPrequest and typically will respond to it. If there are no IPX fileservers on that network segment, but one or more such servers existssomewhere on the interconnected network, then at least one IPX router onthe network segment will respond to the SAP request. It should be noted,however, that the servers and/or routers on the network (if any) willrespond to only the particular frame type that they are configured for,and that they will respond using the frame type they are configured for.The requests embedded in other frame types will not be interpreted asvalid requests by another device on the network unless it is configuredfor that frame type, and thus such requests will not elicit responsesfrom the other devices.

[0038] The requesting device then checks whether any responses to theSAP requests in any of the frame types are received within a particularperiod of time, step 310. According to one embodiment of the presentinvention, this particular period of time is two seconds, however,different periods can be used in different embodiments. In oneimplementation, the period of time to wait is determined by balancingthe desire to not wait too long for a response which should typicallycome quickly against the desire to make sure a response is not misseddue to network traffic or a particularly busy server. Typical periods oftime to wait range from one-half second to ten seconds.

[0039] If a response(s) is received within the period of time, then therequesting device records the frame type of the received response(s),step 315. Each response indicates to the requesting device that anotherdevice on the network is using the frame type of the response. Thus, thedevice knows it can communicate with at least one other device on thenetwork using that particular frame type. It should be noted that it isthe receipt of a response to the SAP request rather than the particularcontent of that response that the requesting device is waiting for.

[0040] If a response(s) to the SAP requests is received, the requestingdevice proceeds after the period of time expires (or alternatively,after all possible frame types have been recorded in step 315), to checkwhether any non-recorded frame types remain, step 320. If all possibleframe types have been recorded in step 315, then the device proceeds tostep 360, discussed in more detail below.

[0041] If any non-recorded frame types remain after step 315, or if noresponses to the SAP requests are received, then the device embeds anIPX diagnostic request in each of the non-recorded frame types andissues the frames on the network, step 325. Thus, the device re-checksall of the possible frame types, except any recorded in step 315, usinga different request.

[0042] The IPX diagnostic request is made by setting the destinationsocket to be that for diagnostic requests (e.g., 0×0456) and inserting adiagnostic request for IPX-SPX components into the packet data. Anydevice on the network segment with an IPX driver installed willtypically respond to the IPX diagnostic request. Thus, if there is aworkstation or other device on the network segment with an IPX driverinstalled, even if there is no file server, and the workstation or otherdevice configured to the selected frame type, then the requesting devicewill receive a response.

[0043] If any responses to the IPX diagnostic requests in any of theframe types are received by the requesting device within a particularperiod of time (e.g., two seconds), step 330, then the requesting devicerecords the frame type of the received response(s), step 335. Analogousto the discussion above, it is the response that the device is waitingfor rather than the contents of any particular response.

[0044] After the period of time expires (or alternatively, after allpossible frame types have been recorded in steps 315 and/or 335), thedevice checks whether any non-recorded frame types remain, step 340. Ifall possible frame types have been recorded in steps 315 and/or 335,then the device proceeds to step 360, discussed in more detail below.However, if any non-recorded frame types remain, then the device embedsan IPX routing information protocol (RIP) request in each of thenon-recorded frame types and issues the frames on the network, step 345.Thus, the device re-checks all of the possible frame types, except anyrecorded in steps 315 and/or 335, using a different request.

[0045] The IPX RIP request is made by setting the destination socket tobe that for RIP requests (e.g., 0×0453) and inserting a RIP request forall networks into the packet data. In one implementation, the RIPrequest issued by the device requests that information for all networksegments of the interconnected network respond. All IPX servers and allIPX routers will typically respond to the RIP request.

[0046] If any responses to the IPX RIP requests in any of the frametypes are received by the requesting device within a particular periodof time (e.g., two seconds), step 350, then the requesting devicerecords the frame type of the received response(s), step 355. Analogousto the discussions above, it is the response that the device is waitingfor rather than the contents of any particular response.

[0047] After the period of time expires (or alternatively, after allpossible frame types have been recorded in steps 315, 335, and/or 355),the device proceeds to select one of the recorded frame types, step 360.These recorded frame types are those from steps 315, 335, and 355.According to one embodiment of the present invention, the selection ismade by presenting a list to the user of the possible frame types andallowing him or her to select one. In this embodiment, the list may bepresented to a user on a remote system. According to one implementation,the device temporarily selects one of the possible frame types (one ofthose recorded from steps 315, 335, and 355). This allows a remotesystem to contact the device, which is done by the remote system sendinga Get Nearest Server SAP request requesting the address of the nearestInstant Internet™ device (performed in an analogous manner to the SAPrequest discussed above with reference to step 305). This allows thedevice and the remote system to communicate with one another, and thusallows the device to identify the possible frame types from thoserecorded in steps 315, 335, and 355 to the remote system, and allows auser of the remote system to select one of the possible frame types.

[0048] Alternatively, the device may be pre-programmed with a particular“preferred” ordering, and it will select the one of the recorded frametypes which is most preferred. In another alternate embodiment, if onlyone frame type is recorded, then that is the only possible configurationoption and the device selects that option automatically without need foruser input.

[0049] It should be noted that the SAP requests, REP requests, and IPXdiagnostic requests discussed above are “broadcast” to all devices onthe network segment rather than being sent to particular devices. Thus,any device on the network segment can respond.

[0050] Thus, following steps 305-355, a list of possible frame types onthe network segment can be identified as long as there is at least oneother device on the network segment (whether it be a router,workstation, file server, gateway, bridge, etc.) using IPX. It is to beappreciated that if there are no other IPX configured devices on thenetwork, then any of the four possible frame types can be selectedbecause there is no other device to be communicating with.

[0051]FIG. 3 illustrates automatic detection of frame type according toone embodiment of the present invention. However, various alternateembodiments of the present invention exist which are modifications tothe embodiment of FIG. 3. According to one such alternate embodiment,the device selects as its frame type the first selected frame type toelicit a response rather than recording all frame types which elicitresponses. According to another such alternate embodiment, the deviceselects as its frame type a “most preferred” from a particular“preferred” ordering as soon as that frame type elicits a response.According to another such alternate embodiment, the device issues arequest embedded in one frame type and waits a period of time for aresponse before sending a request embedded in another frame type.According to another such alternate embodiment, requests for all frametypes are issued regardless of which may have been stored (e.g., in step315, step 335, and/or step 355) from previous requests or previous frametypes of the same request.

[0052]FIG. 4 is a block diagram illustrating a network system in whichone embodiment of the present invention is practiced. An interconnectednetwork is illustrated including two network segments 420 and 430coupled together via a router 440. Multiple (Y) client systems 410, 411,and 412 are coupled to network segment 420, while one or more (N) clientsystems 413 are coupled to network segment 430. A server 415 is alsocoupled to network segment 420. Server 415 provides a service to theclient systems 410-413. By way of example, server 415 may be a fileserver or a print server.

[0053] In the illustrated embodiment network segments 420 and 430together comprise a local area network (LAN) of any of a wide variety ofconventional types, such as an Ethernet or Token Ring network. The LANconforms to any of a wide variety of conventional networking protocols,such as the Windows 95™, Windows NT™, or Novell Netware™ networkingprotocols.

[0054] The network system 400 also includes a gateway 450. The gateway450 provides an interface between the Internet and network segments 420and 430. Requests from one of the client systems 410-413 are received bythe gateway 450 in accordance with the protocol of the LAN. The gateway450 then forwards the requests to the Internet, either directly or viaan ISP. Similarly, data from another system on the Internet whichtargets one of the client systems 410-413 (e.g., a response to anInternet request sent by one of the client systems) is received by thegateway 450 and forwarded to the appropriate client system 410-413 usingthe protocol of the network 440. In one implementation, the gateway 450is an Instant Internet¹⁰⁰™ device available from Bay Networks, Inc.

[0055]FIG. 5 illustrates a hardware system or machine on which oneembodiment of the present invention can be practiced. In one embodiment,the hardware system 101 illustrated in FIG. 1 and the gateway 450illustrated in FIG. 4 are each a hardware system 500 of FIG. 5. In theillustrated embodiment, hardware system 500 includes processor 502 andcache memory 504 coupled to each other as shown. Additionally, hardwaresystem 500 includes high performance input/output (I/O) bus 506 andstandard I/O bus 508. Host bridge 510 couples processor 502 to highperformance I/O bus 506, whereas I/O bus bridge 512 couples the twobuses 506 and 508 to each other. Network/communication interface 516 andsystem memory 514 are coupled to high performance I/O bus 506, andadditional I/O ports 518 are coupled to I/O bus 508. I/O ports 526 areone or more serial and/or parallel communication ports used to providecommunication between additional peripheral devices which may be coupledto hardware system 500. Collectively, these elements are intended torepresent a broad category of hardware systems, including but notlimited to the Instant Internet™ device available from Bay Networks ofSanta Clara, Calif., or general purpose computer systems based onprocessors available from Intel Corporation of Santa Clara, Calif., fromAdvance Micro Devices (AMD) of Sunnyvale, Calif., from NationalSemiconductor of Sunnyvale, Calif., or from Digital EquipmentCorporation (DEC) of Maynard, Mass.

[0056] These elements 502-518 perform their conventional functions knownin the art. In particular, network/communication interface 516 is usedto provide communication between system 500 and any of a wide range ofconventional networks, such as an Ethernet, token ring, the Internet,etc. It is to be appreciated that the circuitry of interface 516 isdependent on the type of network the system 500 is being coupled to. Inone implementation, hardware system 500 is coupled to network segment420 of FIG. 4 via network/communication interface 516. One or moreadditional network/communication interfaces (not shown) may also becoupled to high performance I/O bus 506 or standard I/O bus 508 forcommunicating with another network, such as the Internet.

[0057] According to one embodiment of the present invention, anonvolatile memory 520, such as a ROM or Flash memory, is also coupledto I/O bus 506 (or alternatively I/O bus 508) to provide permanentstorage for data and programming instructions to perform the abovedescribed functions of automatic frame type detection of FIG. 3, whereassystem memory 514 is used to provide temporary storage for the data andprogramming instructions when executed by processor 502. According to analternate embodiment of the present invention, nonvolatile memory 520also provides permanent storage for data and programming instructionswhich enable the hardware system 500 to receive additional data andprogramming instructions from another network device (such as a clientsystem 410-413 of FIG. 4) via interface 516 and store the data andinstructions in the system memory 514.

[0058] It is to be appreciated that various components of hardwaresystem 500 may be rearranged. For example, cache 504 may be on-chip withprocessor 502. Alternatively, cache 504 and processor 502 may bepackaged together as a “processor module” and attached to a “processorcard”, with processor 502 being referred to as the “processor core”.Furthermore, certain implementations of the present invention may notrequire nor include all of the above components. For example, cache 504or I/O ports 518 may not be included in system 500. Additionally, theperipheral devices shown coupled to standard I/O bus 508 may be coupledto high performance I/O bus 506; in addition, in some implementationsonly a single bus may exist with the components of hardware system 500being coupled to the single bus. Furthermore, additional components maybe included in system 500, such as additional processors, mass storagedevices, memories, video memories, display devices, keyboard devices,pointing devices, etc.

[0059] In alternate embodiments of the present invention, hardwaresystem 500 is less complex than illustrated. By way of example,processor 502, system memory 514, and network/communication interface524 could be implemented in a microcontroller or an application specificintegrated circuit (ASIC).

[0060] In one embodiment, the method of FIG. 3 is implemented as aseries of software routines run by hardware system 500 of FIG. 5. Thesesoftware routines comprise a plurality or series of instructions to beexecuted by a processor in a hardware system, such as processor 502 ofFIG. 5. Initially, the series of instructions are stored on a storagedevice, such as nonvolatile memory 520. It is to be appreciated that theseries of instructions can be stored on any conventional storage medium,such as a hard disk, removable diskette, CD-ROM, magnetic tape, DVD,laser disk, etc. It is also to be appreciated that the series ofinstructions need not be stored locally, and could be received from aremote storage device, such as a server on a network, vianetwork/communication interface 516.

[0061] The instructions are copied from the storage device (or remotesource) into memory 514 and then accessed and executed by processor 502.In one implementation, these software routines are written in the Cprogramming language. It is to be appreciated, however, that theseroutines may be implemented in any of a wide variety of programminglanguages.

[0062] In alternate embodiments, the present invention is implemented indiscrete hardware or firmware. For example, in one alternate embodiment,an application specific integrated circuit (ASIC) is programmed with theabove described functions of the present invention.

[0063]FIG. 6 is a block diagram illustrating a device on which oneembodiment of the present invention is implemented. The device 600represents a wide variety of machine-readable media in which the presentinvention can be implemented, including conventional storage devices(such as a floppy disk, random access memory, or Flash memory), as wellas discrete hardware or firmware.

[0064] The device 600 includes a frame detection portion 602 and an IPXstack portion 604. In embodiments where the present invention isimplemented in software or firmware, frame detection portion 602includes the instructions, to be executed by a processor, for carryingout the automatic frame detection of FIG. 3. Similarly, IPX stackportion 604 includes the instructions, to be executed by a processor,for communicating with other devices via the network according to theIPX protocol. In embodiments where the present invention is implementedin hardware, frame detection portion 602 includes the logic for carryingout the automatic frame detection of FIG. 3. Similarly, IPX stackportion 604 includes the logic for communicating with other devices viathe network according to the IPX protocol.

[0065] Thus, a method and apparatus for automatic frame type detectionin a network has been described. Whereas many alterations andmodifications of the present invention will be comprehended by a personskilled in the art after having read the foregoing description, it is tobe understood that the particular embodiments shown and described by wayof illustration are in no way intended to be considered limiting.References to details of particular embodiments are not intended tolimit the scope of the claims.

What is claimed is:
 1. A computer-implemented method comprising:automatically identifying at least one frame type in use on a network;and selecting one of the at least one frame types for a device coupledto the network to use.
 2. The method of claim 1, wherein the identifyingcomprises: issuing a plurality of different requests on the network eachusing a plurality of different frame types; and checking which requestsand which frame types elicit responses.
 3. The method of claim 2,wherein the plurality of different requests includes one or more of aservice advertising protocol (SAP) request, an IPX diagnostic request,and an IPX routing information protocol (RIP) request.
 4. The method ofclaim 2, wherein the plurality of different frame types includes one ormore of an Ethernet_II frame type, an IEEE 802.2 frame type, an IEEE802.3 frame type, and an Ethernet_SNAP frame type.
 5. The method ofclaim 1, wherein the identifying comprises: issuing a first request onthe network using at least one of a plurality of different frame types;and checking whether the at least one of the plurality of differenttypes elicits a response to the first request.
 6. The method of claim 1,wherein the selecting comprises: providing an option list including atleast one of the at least one frame types in use on the network; andselecting a chosen frame type from the option list as the frame type touse.
 7. A machine-readable medium having stored thereon a plurality ofinstructions, designed to be executed by a processor, for implementing afunction for automatically identifying at least one frame type in use ona network, and for selecting one of the at least one frame types for adevice coupled to the network to use.
 8. The machine-readable medium ofclaim 7, wherein the plurality of instructions for implementing afunction for identifying comprises a plurality of instructions forimplementing a function for issuing a plurality of different requests onthe network each using a plurality of different frame types and checkingwhich requests and which frame types elicit responses.
 9. Themachine-readable medium of claim 8, wherein the plurality of differentrequests includes one or more of a service advertising protocol (SAP)request, an IPX diagnostic request, and an IPX routing informationprotocol (RIP) request.
 10. The machine-readable medium of claim 8,wherein the plurality of different frame types includes one or more ofan Ethernet_II frame type, an IEEE 802.2 frame type, an IEEE 802.3 frametype, and an Ethernet_SNAP frame type.
 11. The machine-readable mediumof claim 7, wherein the plurality of instructions for implementing afunction for identifying comprises a plurality of instructions forissuing a first request on the network using at least one of a pluralityof different frame types and for checking whether the at least one ofthe plurality of different types elicits a response to the firstrequest.
 12. The machine-readable medium of claim 7, wherein theplurality of instructions for implementing a function for selectingcomprises a plurality of instructions for providing an option listincluding at least one of the at least one frame types in use on thenetwork, and for selecting a chosen frame type from the option list asthe frame type to use.
 13. An apparatus comprising: network controllogic to control communication over a network; and frame detectionlogic, coupled to the network control logic, to automatically identifyat least one frame type in use on a network and to select one of the atleast one frame types for the network control logic to use.
 14. Theapparatus of claim 13, wherein the frame detection logic is to identifythe at least one frame type by issuing a plurality of different requestson the network each using a plurality of different frame types andchecking which requests and which frame types elicit responses.
 15. Theapparatus of claim 14, wherein the plurality of different requestsincludes one or more of a service advertising protocol (SAP) request, anIPX diagnostic request, and an IPX routing information protocol (RIP)request.
 16. The apparatus of claim 14, wherein the plurality ofdifferent frame types includes one or more of an Ethernet_II frame type,an IEEE 802.2 frame type, an IEEE 802.3 frame type, and an Ethernet_SNAPframe type.
 17. The apparatus of claim 13, wherein the frame detectionlogic is to identify the at least one frame type by issuing a firstrequest on the network using at least one of a plurality of differentframe types and checking whether the at least one of the plurality ofdifferent types elicits a response to the first request.
 18. Theapparatus of claim 13, wherein the frame detection logic is to selectthe one of the at least one frame types by providing an option listincluding at least one of the at least one frame types in use on thenetwork, and selecting a chosen frame type from the option list as theframe type to use.
 19. An apparatus comprising: means for automaticallyidentifying at least one frame type in use on a network; and means,coupled to the means for automatically identifying, for selecting one ofthe at least one frame types for a device coupled to the network to use.20. The apparatus of claim 19, wherein the means for automaticallyidentifying comprises: means for issuing a plurality of differentrequests on the network each using a plurality of different frame types;and means for checking which requests and which frame types elicitresponses.
 21. The apparatus of claim 20, wherein the plurality ofdifferent requests includes one or more of a service advertisingprotocol (SAP) request, an IPX diagnostic request, and an IPX routinginformation protocol (RIP) request.
 22. The apparatus of claim 20,wherein the plurality of different frame types includes one or more ofan Ethernet_II frame type, an IEEE 802.2 frame type, an IEEE 802.3 frametype, and an Ethernet_SNAP frame type.
 23. The apparatus of claim 19,wherein the means for automatically identifying comprises: means forissuing a first request on the network using at least one of a pluralityof different frame types; and means for checking whether the at leastone of the plurality of different types elicits a response to the firstrequest.
 24. The method of claim 19, wherein the means for selectingcomprises: means for providing an option list including at least one ofthe at least one frame types in use on the network; and means forselecting a chosen frame type from the option list as the frame type touse.